SQL vs NoSQL
Sokan vannak ma még, akik felteszik azt a nagyszerű kérést, hogy mi fán is terem az a NoSQL? Nagy vonalakban ez is adattárolási módszer, de teljesen más elveken nyugszik, mint a hagyományos RDBMS, azaz strukturált adatbázisok adattárolási módszere. Leginkább JSON szerű adatfájlokat használ és nem adattáblákat, valamint minden egyes entitásnak saját külön dokumentuma (fájlja) van, amelyek között az azonos mezőnév+érték párossal lehet kapcsolatot teremteni.
Elsősorban ott alkalmazzák, ahol nem annyira döntő a struktúrált adattárolás, hanem inkább a nagy mennyiségű adatok minél gyorsabb lekérdezése az elsődleges.
GYIK, azaz a döntő kérdések, amelyek felmerülhetnek akkor, amikor dönteni kell, hogy melyiket is válasszuk:
- milyen adataim vannak?
- jelenlegi adatainkat hogyan tároljuk?
- mennyire fontos az adatbázis tranzakciók pontossága?
- mennyire fontos a sebesség?
- esetleg fel tudjuk-e osztani az adatokat aszerint, hogy mind az RDBMS, mind a NoSQL előnyeit ki tudjuk használni?
Pár fontos információ a NoSQL és hagyományos RDBMS kapcsán, ami döntő lehet:
Robosztusság, biztonság, szabadság kérdése:
- az RDBMS már sok évtizede létezik, mögötte ugyanennyi tapasztalat is van, szemben a NoSQL-lel, ami igazából az elmúlt évtizedben terjedt el nagyobb körben
- ezáltal a rdbms rendkívül sokoldalú, nagyon komplex lekérdezéseket, alkalmazásokat lehet rajta futtatni
- biztonságos olyan szempontból, hogy már a tervezése során el kell dönteni a pontos adatbázis struktúrát, a táblákat, mezőket, típusokat, kapcsolatokat, stb.
- amennyiben viszont ez a stabilitás nem olyan fontos számunkra, és megfelelő számunkra a nagyobb szabadság, akár az is, hogy akár minden entitás/dokumentum eltérő mezőkkel rendelkezhet, akkor a NoSQL is jó választás lehet
- ezzel szemben amennyiben az igény a biztos alapokon nyugvó, multi-row tranzakciók futtatása, akkor a hagyományos SQL lehet a megfelelő
Skálázhatóság:
- amennyiben arról van szó, hogy mindennél döntőbb a lekérdezések gyorsaságának igénye, akár a fentebbi biztos háttér oltárán is, akkor a NoSQL jó választás lehet. A NoSQL ugyanis horizontálisan (azaz akár dokumentum szinten) is skálázható, nem csak a nagyobb RDBMS féle módszerrel, amikor sok esetben csak a több RAM, CPU segíthet a hatékonységon (ha már minden indexelési, kód javítási kísérleten túlestünk persze)
- emiatt nagy mennyiségű adat tárolása esetén a NoSQL megoldások általában jóval nagyobb hatékonyságot, sebességet tudnak nyújtani
- fontos viszont, hogy mivel teljesen más a két adatbázis forma adattárolási módja, ezért az SQL a hagyományos, több táblára osztott, redundancia és adat duplikáció mentes, robosztus SQL lekérdezésekben megfelelő sebességet tud nyújtani
- másik oldalról viszont a strukturálatlan, nagy méretű adatbázisok esetében a NoSQL igen jó eredményt tud nyújtani.
A döntéshez tehát a fenti alapelveket érdemes figyelembe venni. Lényeg, hogy minden attól függ, hogy mire akarjuk használni. Lehet, hogy a Google NoSQL-t használ, de egy biztonságos, kevesebb adattal dolgozó stabil hátterű banki rendszernél lehet hogy inkább az SQL lesz a jó választás. A döntés minden esetben sok tényezős kérdés, ezért itt sem lehet egzakt választ adni erre a kérdésre.
Legközelebb folytatjuk egy kis MongoDB ismerkedéssel, ami a NoSQL adatbázisok egyik zászlóshajója manapság, és konkrét példákkal nézzük át a MongoDB alapjait, sőt még Spring-ben is összedobunk egy API-t, ami a MongoDB adatait szedi át.
